[レポート]Accelerate application maintenance and upgrades with generative AI #DOP209 #AWSreInvent
はじめに
今回はre:Invent2024のセッション 「Accelerate application maintenance and upgrades with generative AI」 について抜粋して紹介していきます。
AWSがJavaの大規模なアップグレードに成功したという話は、確か昨年のre:Inventで聞いた気がするので興味あるため聞いてみました。アプリのアップグレードなどに取り組んでる方は是非読んでください。
セッションの概要
Accelerate application maintenance and upgrades with generative AI
「生成 AI を使用してアプリケーションのメンテナンスとアップグレードを加速」
概要文(Youtubeより)
Developers spend significant time completing the undifferentiated work of maintaining and upgrading legacy applications. Teams need to balance investments in building new features with mandatory patching and update work. Now, using the power of generative AI, the Amazon Q Developer agent for code transformation can expedite these critical upgrade tasks, transforming applications to use the latest language features and versions in hours or days and saving significant costs. Join the session to learn what's new and how your team can automate Java application upgrades.
翻訳
開発者は、レガシーアプリケーションの保守とアップグレードという差別化されない作業に多大な時間を費やしています。チームは、新機能の開発への投資と、必須のパッチ適用やアップデート作業のバランスを取る必要があります。現在、生成AIの力を活用することで、コード変換のためのAmazon Q Developer エージェントは、これらの重要なアップグレード作業を迅速化し、最新の言語機能やバージョンを使用するようアプリケーションを数時間または数日で変換し、大幅なコスト削減を実現できます。このセッションに参加して、新機能と、チームがJavaアプリケーションのアップグレードを自動化する方法について学びましょう。
登壇者(発表順)
- Adnan Bilwani氏 (AWS/Principal Specialist)
- Amber Bird氏 (Canada Life/AVP,Engineering)
- Elio Damaggio氏 (AWS/Principal Product Owner)
セッション内容
目次
- Upgrading legacy application
- Canada Lifeの事例
- What's new?
Upgrading legacy application
Adnan Bilwani氏より
まず議論のベースラインを設定します。以下のように5つの観点がありますが、今回はどれを取り上げるでしょうか。
Infra, OS, Framework&package, Application Code&dataなど様々なレイヤーでアップグレードは必要になります。また組織のフェーズによっていつ行うべきかも変わってきます。今回は2つの層での活用について話します。
人々はこのアップデートを行うために、自動作業と手動作業を組み合わせています。メンテナンスが手動か自動かの割合は、システムの成熟モデルの段階によって異なります。会場からは20:80という声もありました。
ここでは次にJava8からJava17にアップデートする例を見てみます。ビルドしてテストし、修正するサイクルを何度か繰り返すでしょう。そのプロセスが自動化できるとしたらどうでしょう?生成AIを活用して、分析、更新、コンパイル、単体テスト追加のフェーズをAmazon Qに学習させてみます。
Amazon Q Developer Agent for code transformationでコードの変換を学習させます。
プロセスをknowledge databaseに保存します。これは完全にうまくいくでしょうか。ボタン一つで完全に解決するものではないですが、最初のステップを50%進んだ状態から始めることができます。
ここからデモが始まります。詳細は動画の12:04~を見てください。
Amazon Q DeveloperのVSCodeのウインドウから/transform
コマンドを実行すると、更新するランタイムバージョンの選択と単体テスト実行可否の入力をするだけ、Javaプロジェクトの中で変更すべき箇所を自動的に特定して変更まで行ってくれます。
変更されたコードの一覧も表示されるので、差分を確認しながら正しい変更かを確認もできます。
Javaパッケージの名前空間の変更やフレームワークやライブラリのバージョンアップなども自動で対応してくれていました。コンパイルエラーの修正までは一部行われなかったので手動で修正されていました。
Canada Lifeの事例
ここからはAmber Bird氏より発表
Canada Lifeは保険、資産管理、ヘルスケアの会社です。従来のプラットフォームではAPIがそれぞれ別にホストされていました。トラブルシュートは悪夢でした。よりセキュアでアプリをモダナイズするための資金を得る絶好の機会でした。
APIを1つにし、レガシーなプラットフォームでの稼働を廃止、DBもクラウド化しプラットフォームを統合する予定でした。
最終的には以下のようなプラットフォームになりました。簡素化したことで運用しやすく、パフォーマンスや顧客体験も向上できました。ただAPIをクラウドにシフトするには、既存の脆弱性をすべて取り除く必要がありました。10年経ってもパッチが当てられていないものも沢山ありました。本当に困ったことになりました。予想のコストが当初の100万ドルから1000万ドルになり、2025年末までかかる想定でした。
多くのJavaの機能を手動でアップデートする必要がありました。そこでAWSを訪ねたとき、Amazon Qと出会いました。当時Amazon Qはプレビューでしたが交渉し、フィードバックする代わりに使わせてもらうことになりました。3つの異なるプラットフォーム(Nucleus/Docker Swarm/Rancher Kubernetes)でAPIを更新をしました。
1人のデベロッパーに一度手動でコードのアップデートを試してもらった後、Amazon Qで自動生成した後に手動でコードのアップデートを試してもらいました。手動に比べて25~45%生産性の向上を狙いました。
Docker Swarm上では50%の生産性向上が見えました。Nucleus上のAPIの更新は11%に留まりました。これは特に古いAPIだったことやカバーされていないcamelフレームワークなどが含まれていたことも原因と考えています。Rancher上の3つめのAPIでは最大23%の向上が見込めました。
上記の結果を元にAmazon Qを改善してもらいre-run(図の右から2番目の丸)すると、今度は最大48%の改善が見られました。またNucleus上のものをre-runすると最大30%改善することがわかりました。これはcamelフレームワークへの対応をしてもらったおかげです。素晴らしい結果でした!
次にAmazon Qで進めたいのは導入の拡大です。次にGenAIの利用拡大、最終的にはAmazon Qとソフトウェア開発の統合です。開発スタックとパイプラインを統合して、自動で脆弱性が修復されるような構成を目指しています。
最終的に、平均40%の生産性向上が達成し、2600時間以上の労力と25万ドルのコストを削減することに成功しました。1000万ドルの中から見ると小規模ではありますが、これは少なく見積もった場合の話です。今後は改善された状態で進みます。
What's new?
Elio Damaggio氏よりコード変換の改善について紹介。まずは品質について。
まずはデバッグフェーズから始めました。Q Code Agentは、Java 8 or 11 から 17に移行しフレームワークの依存関係を更新し、非推奨のAPIをすべて削除します。これはApply knowledge baseのフェーズで発生します。ナレッジにはフレームワークの最適なバージョンや非推奨なAPIのアップデート方法などが含まれています。ただ知識ベースの変換だけでは未対応のものも含まれます。ビルドとデバッグのフローをエージェントで何度か繰り返します。
デバッグエージェントはビルドエラーを1つずつ解析し、対処していきます。数週間前からの機能には別のステップを追加しました。複数のエラーコンテキストを与え、エージェントによりよい解決策を考えさせます。また複数のツール使用をエージェントに許可し、コードベースの参照や複数ファイルの更新をなど許可しました。何が機能し、何が機能しなかったのかも記録させます。これでハルシネーションが減ります。最後にエージェントに後戻りさせる機能を追加しました。
コードのエラーに対して、メモリマネージメントエージェントや自己批判エージェント、デバッグエージェントがそれぞれ裏でやりとりし、最適なコードを提案し自動修正します。ビルドが成功するか、リソースがなくなるまでこの処理は続きます。
この後は例でimport漏れに対して網羅的にimportが追加されることを確認していました。
これによりデバッグのパフォーマンスが85%向上しました。これは継続して監視し続けています。
次に何が起きるでしょうか。このエージェントを使うアプローチは複数ファイルで計画を立てられます。今後単なるデバッグを超えて、すべての開発のコード変換にエージェントを使うことを計画しています。
顧客リクエストの対応として、大規模なシステムでの移行のレビューが困難なので最低限のアップデート方法やアプリケーションの継続的な更新が依頼されています。Qでは最小限のバージョンアップ、ライブラリを分析し最適なアップデートグレードパスを提供しています。
ここからは再度デモで紹介されました。時間は41:54付近です。
Java 17への更新後も、Qでライブラリやフレームワークの更新に対応できることが確認できます。これにより、アプリを常に最新の状態に整えることができます。
さらに、コマンドラインでより大規模に扱うことが簡単になるかもしれないです。これは現在プレビューです。
qct-cli
を使うことで、独自のスクリプトやCICDパイプラインに統合できます。CICDに統合すれば、アプリを常に最新のバージョンに揃えることもできます。変換内容をカスタムしたい場合は、yamlで指定できるよう準備しています。
最後に紹介したアップデートの確認です。Q Code Agentのマルチエージェントによってデバッグパフォーマンスは85%改善します。また継続的なアップデートも重要です。モダナイゼーションは最新化だけでなく、新しく更新し続ける必要もあります。このためにライブラリだけのアップデート機能も提供しました。CLIサポートもプレビューで提供し始めています。
この機能はQ Developerをいれるだけで使用できるので試してください。というような話で締められました。
所感
Javaのモダナイゼーションをやる機会は無いのですが、気になっていたので面白い内容でした。特にAmazon Q Developer エージェントの中に複数のエージェントがあって、それぞれの役割でサイクルしてコードを生成している部分は今後いろんなアプリのモダナイゼーションで活躍しそうな気がしました。欲をいうと古いPythonやNodeのバージョンアップもこれでできたら嬉しいななど考えてました。
Javaのモダナイゼーションで悩んでる方は、是非Amazon Q Developer エージェントを使ってみてください!